CURRENT_MEETING_REPORT_ Reported by Abel Weinrib/Bell Communications Research Minutes of the Multiparty Multimedia Session Control Working Group (MMUSIC) An on-line copy of the minutes and the accompanying slides are available in the directory ftp.isi.edu:confctrl/minutes as files ietf.7.94 and slides.7.94.tar. The Multiparty Multimedia Session Control (MMUSIC) Working Group held one session at the IETF meeting in Toronto. This session focused on reports from implementors of a range of multimedia conferencing applications. The goal was to identify common ground for interoperability. The agenda included Dick Cogger who talked about architectural issues in CUSeeMe, a Macintosh-based conferencing tool. Ron Frederick spoke about the Jupiter project that is providing audio, video and shared windows for MOO systems. Carsten Bormann presented a reliable multicast protocol similar to MTP that they have designed and implemented to support their Xy shared window system. Ian Wakeman gave an update on the CCCP communication and control protocol being developed to support conference control. Joerg Ott described the ITU T.gcc standardization efforts. Abel Weinrib provided an update on an implementation of the agreement algorithm being developed by Ted Ko at Bellcore as a Masters project. Finally, Eve Schooler spoke about interoperability, defining the various interfaces that, if standardized, would facilitate interoperation of different applications and media agents. Architectural Issues in CUSeeMe The slides from Dick Cogger's presentation follow these minutes. In this talk, Dick Cogger argued for having an integrated user interface (UI) that is connected to conference control and central bandwidth management. The major components of the CUSeeMe system include the user interface, conference control, and a bandwidth manager, along with modules for audio, video and a window for displaying slides; it also provides a plug-in interface that allows for the addition of other add-on applications. The CUSeeMe system uses a reflector running on a UNIX system that simulates multicast. It has been tempting to add additional functionality to the reflector. Currently, the reflector prunes a stream back to its source to conserve bandwidth when no one wants to receive the stream, which is particularly valuable on low-bandwidth links. Dick argued that the UI and conference control should interact so that the control status information can be used to control elements in the UI that indicate what other users are doing and what they are capable of. They have not yet come up with a clean separation that would decide whether this information should be sent in RTCP messages or as part of general session control. Bandwidth management in CUSeeMe is based on a bandwidth cap that is adapted based on loss reports from receivers. This approach may be problematic if there are heterogeneous receivers that have differing amounts of available bandwidth. Audio is given priority (if anyone wants to hear you) and sending of video is subject to the cap (if anyone wants to see you). Jupiter Video Protocol The slides from Ron Frederick's presentation (slides.7.94.a) follow these minutes. The goal of the Jupiter project is to extend a MOO system (text-based social virtual realities) to include audio, video and shared windows. They are developing a local client that speaks RTP, HTTP, etc. Each client is controlled by a TCP connection to the central MOO server. Currently, the client is running under UNIX and Windows; a Macintosh version will be done soon. The MOO server plays a coordinating role. It provides permanent storage of information, key management, multicast address management, and sharing of window state (whiteboard, etc.). The central server also prunes media streams back to their sources if no one wants to receive them, and allows control of bandwidth. Their longer term plan is to do a distributed server implementation to avoid the single point of failure and performance bottlenecks of the central server and to better cope with user communities spread across administrative domains. The Jupiter client is really a media agent, having no inherent UI. Rather, the server downloads a window layout into the client, and widget events are sent back to the server for action. The video client supports a ``videosend'' protocol that allows the server to request a list of available video sources, set the TTL, start a video stream from a source to a destination, stop a video stream (to a particular destination, or to all) and to set video attributes. Video reception is supported by a ``videoPane'' widget that shows one video source of any size. Reliable Multicast and Groupware Applications The slides from Carsten Bormann's presentation (slides.7.94.b) follow these minutes. Carsten spoke about a reliable multicast protocol that they have developed. The goal was to develop a multicast protocol built on top of IP multicast that is optimized for groupware applications. In particular, their objectives included scalability (not linear algorithm), efficiency, robustness (perhaps more important than strict ``reliability'') and message ordering (to make the application programmer's life easier). Their protocol, MTP2, is based on MTP (RFC 1301). It has one master and many producers and consumers of messages. Global ordering is sequenced by the master with use of a token, and the master can control the message rate by limiting the transmission of the token. The protocol also supports atomicity, and addresses scalability with the use of unicast negative acknowledgments. The protocol has a ``heartbeat,'' and after some number of heartbeats the sender discards the message. Additional features of the MTP2 protocol include request of message retransmission from anyone, not just the sender; allowing unsequenced messages as well as sequenced ones; and master loss recovery and migration. The MTP2 protocol has been used for the Xy window sharing system, which is based on multicast from the Xy server to agents on each workstation. It also underlies the Sharekit application replication toolkit that allows the creation of cooperation-aware applications by layering Sharekit between the GUI and the application engine of applications structured in that way. CCCP Prototype The slides from Ian Wakeman's presentation (slides.7.94.c) follow these minutes. Ian gave an update on the CCCP protocol that was talked about at length during the Seattle IETF. There is an implementation of CCCP, and it has been used to create a floor control agent. They plan to release the implementation in mid-August. ITU GCC Work Joerg Ott talked about the work to standardize ``Generic Conference Control'' within the ITU. It should be released as a standard by early next year. GCC coordinates membership and integrates applications, including functions to establish conferences, provide a conference roster and an application roster and registry, and manage conductorship. It does not support floor control. GCC relies on BMCS, an underlying multicast communication service that offers reliability, optional global ordering, admission control, multiplexing and token management. BMCS is realized with reliable flow-controlled transport on point-to-point links on a hierarchy of multipoint control units; the top MCU controls membership, etc. Despite the considerable overlap in interests, the people working on GCC do not know what is going on at IETF, and we know little of what they are doing. We are exploring the possibility of developing a liaison with this effort. Agreement Service Update Abel Weinrib briefly discussed the work being done at Bellcore to create an ``agreement engine'' that implements the agreement algorithm which has been discussed at previous MMUSIC meetings. Ted Ko from MIT is doing his Masters thesis on this topic at Bellcore. It is envisioned that the agreement algorithm will form the foundation for a general session control protocol. Interoperability Report The slides from Eve Schooler's presentation (slides.7.94.d) follow these minutes. Eve discussed work being started to demonstrate interoperability between existing conferencing implementations. There is a commonality in the architectures of many of these implementations, with some sort of session manager function doing coordination ``horizontally'' (peer to peer) between session managers, and ``vertically'' controlling the media agents that provide the media transport for the conferences. An open question is whether the vertical and horizontal interfaces should use the same underlying communication mechanism. There are many session orchestration approaches (sd, mmcc, maven, ivs, dvc, comet on WWW, mmphone over e-mail). One goal is to create a common session description that they can all use. There are many ways to communicate with media agents, including CCCP, Tk-send and multicast with a TTL of zero. It would be good to choose one, and to come up with a common control interface to be used by all media agents. Such a control interface should include at least ``on/off'' control for multi-agent muting, channel surfing, channel selection, and floor moderation, as well as up-calls from the media agents to support video-to-follow-audio, adaptive QoS tradeoffs, inter-agent synchronization and the like. The overall goal is to create a ``plug and play'' environment in which application developers can choose between a variety of session control agents and media agents. What is needed now is the documentation of control interfaces to existing media agents, and of session agent protocols. Discussion In the ensuing discussions, several implementors agreed to document the protocols that are presently in use, to outline improvements planned for future releases, and in some cases actually to work on interoperation. There were at least two reasons for promoting documentation efforts. First, it would be useful to provide Informational RFCs for many of the publicly available applications. Second, write-ups would go a long way towards motivating production of a shared protocol or protocols. It was also suggested that it might be useful to hold a workshop to bring together people interested in these problems around the same time as the next IETF meeting in San Jose, possibly hosted by SRI.