Internet Engineering Task Force D. Trossen (Editor) Internet Draft Nokia Research draft-trossen-conferencing-problem-00.txt 06. November 2001 Expires: 06. May 2002 Conference Course Control Problem Statement Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) The Internet Society (2001). All rights reserved. Abstract As part of the Internet Multimedia Conferencing Architecture [3], conference course control deals with the control of running conferences after the creation of the initial conference state with respect to the membership and access control during runtime of the session. The spectrum of scenarios reaches from small multiparty gatherings up to large scaled meetings with a high fluctuation of userÆs membership and activity. This document identifies the problem areas to define the scope of conference course control efforts within the IETF. Trossen Expires November 2001 [1] Internet Draft Course Control Problem Statement May 2001 Table of Contents 1. Introduction...................................................2 2. Definition of Terms............................................3 3. Scope..........................................................4 4. Problem Statement..............................................4 5. Conferencing Scenarios.........................................5 5.1. Simple Conferencing.........................................5 5.1.1. Examples..................................................6 5.2. Floor Controlled Conferencing...............................6 5.2.1. Examples..................................................7 5.3. Rich Conferencing...........................................7 5.3.1. Examples..................................................7 5.4. Summary of Characteristics..................................8 6. Conference Course Control Models...............................9 6.1. Loose Conference Course Control.............................9 6.2. Tight Conference Course Control.............................9 6.3. 'Jelly-like' Conference Course Control.....................10 7. Existing Solutions............................................10 7.1. H.32x Protocol Suite.......................................10 7.2. SIP-based Solutions........................................11 7.3. Transport Layer Solutions..................................11 8. Next Steps....................................................11 9. Security Considerations.......................................12 10. Acknowledgements............................................12 11. References..................................................12 1. Introduction Interactive collaborative scenarios like remote meetings, virtual classrooms, or sharing applications via the Internet have become more and more popular in the past ten years. According to [3], the term 'conferencing' is considered in the remainder of this document as synchronous, real-time communication, specifically including audio and video media but also shared data media such as whiteboards, among a set of members. Several, probably independently implemented, agents for media handling and control purposes have to be coordinated and synchronized during runtime of the conference, referred to as 'conference course control' in the following, after creating the initial conference state as part of the conferencing setup functionality. The provided functionality with respect to conference course control usually depends on the considered scenario in which it is needed. In the following, the scope of conferencing course control as well as a problem statement will be pinpointed. Furthermore, scenarios for multimedia conferencing in the Internet are categorized, Trossen Expires November 2001 [2] Internet Draft Course Control Problem Statement May 2001 reaching from small closed meetings to large plenary sessions with high fluctuations regarding the participantÆs activity and interests. Since the focus of the document is on control issues in conferencing, data delivery aspects are left out of consideration. The scenario findings are then used to define models for conference course control provision. Moreover, current conferencing solutions are briefly evaluated concerning their shortcomings in conference course control functionality. Finally, next steps for conference course control efforts will be presented. 2. Definition of Terms o Application session (AS), Session The set of media agents/applications that act as peers to each other within a conference. For real-time data, this generally will be an RTP session; for other application protocols, other horizontal protocols may define their own type of session concept. o Participant A human being that takes part in a conference, either actively or passively listening. o Active Participant A participant of a conference becoming sender of media information during lifetime of the conference. o Passive Participant A participant of a conference passively receiving the media information without becoming sender of media information during lifetime of the conference. o Member The system, including software and hardware, that takes part in a computer conference, representing a single participant. o Profile An initial description of the conference, including assignment of roles to particular members, time limits for speakers, attributes of the conference (open/close, conducted/anarchic, etc). o Conference Setup and Discovery According to [3], aspects for setting up an initial conference State in participating members, including the exchange of media and capabilities information among the set of participants, are being addressed by setup and discovery functionality. o Conference Course Control According to [3], aspects to control the conference during runtime of the event are being addressed by conference course control. Trossen Expires November 2001 [3] Internet Draft Course Control Problem Statement May 2001 o Membership Model A certain model assumed for the membership of a session. In the remainder of the document, the following models are considered: * open model : everyone can join a session without restriction * closed model : only pre-determined, pre-announced, or end systems determined during runtime can join a session * static model : the group of participants does not change during runtime of the session. * dynamic model: the group of participants might change during runtime of the session. The following combinations are considered in the remainder of the Document: open, closed/static, closed/dynamic 3. Scope The scope of conference course control functionality will be developed as part of the solution space. Possible functionality includes: o 'conference context administration', providing membership and application/session information administration o 'membership enforcement', providing means to enforce specific conference membership o 'floor control', providing means to map social protocols onto distributed environments. However, the semantics of specific social protocols is not within the scope of the possible conference course control solution. o 'active/passive member support', allowing for different policies with respect to membership and floor control. This includes changes from active to passive and vice versa, either implicitly or explicitly. o 'capabilities re-negotiation', allowing for changes in the initial capabilities set of participants during runtime of the conference. o 'transport requirements', defining the requirements of underlying transport protocols to provide certain functionality regarding conference course control This list does not claim to be exhaustive. However, it points in the direction of provided functionality for conference course control solutions. 4. Problem Statement There are many approaches in the research community to realize conference course control as part of a conferencing architecture. Also in standardization bodies (such as H.323 [7] or SCCP [1]), conference course control has been addressed. However, none of these approaches offers a unified and flexible solution for conference course control to cover the spectrum of scenarios outlined in Section 5. Trossen Expires November 2001 [4] Internet Draft Course Control Problem Statement May 2001 Specifically, a conference course control solution should o fit into the already defined conference control architecture and leverage the existing suite of mechanisms and protocols, such as * conference description, i.e., SDP [4] or future versions (SDG-ng [9]), and initiation, i.e., SIP [5] * local coordination, i.e., MBUS [10] * transport layer protocols, such as for reliable multicast, real- time transfer, or simple unicast transmission * security components, such as group key solutions o provide a flexible solution, allowing for a variety of scenarios (see Section 5) and characteristics to be plugged in the system. For that, a building block approach would allow the provision of standardized interfaces to the desired common functionality. With that, specific scenario-tailored instantiations for certain functionality, represented by a building block, are enabled preserving the common view of the conference course control functionality. 5. Conferencing Scenarios This section informally outlines scenario categories for multimedia conferencing in the Internet. The conferencing scenarios are categorized in three sections. For each category, typical characteristics are outlined, and examples are given. Finally, a table-wise overview is derived from the more informal description pinpointing the very functionality required for the specific scenarios. This table-wise description will be used in Section 5 to discuss conference course control models. It is worth mentioning that simple streaming is not considered in the following due to its lack of conference course control functionality. However, it might be used to realize very simple conferencing scenarios such as Internet lectures, where data is simply sent to a set of receivers without feedback or interaction. 5.1. Simple Conferencing 'Simple Conferencing' reflects the simplest form of conferencing with a change of the sender/receiver relation based on certain 'social rules' during the lifetime of the conference. Conferences of this type might be announced beforehand, including the conferenceÆs profile information, or they take place as ad-hoc meetings. The group of participants might be well-known, if announced, or be built by invitation or request. For that, several initiation models might be realized (see also [11]), which requires appropriate Trossen Expires November 2001 [5] Internet Draft Course Control Problem Statement May 2001 initiation functionality including authentication and authorization means for restricted access to the conference. Floor control functionality, e.g., to realize conducted meeting functionality, is not provided in this category. Due to this lack of mediation concerning the access on the common media resource, the level of interactivity is usually limited, even if scalable multicast transfer is used. Usually, the initial set of capabilities is not changed, i.e., re- negotiated, during runtime of the conference. However, some simple form of re-negotiation could be provided. Although the number of participants can easily reach several thousands or even more, when using multicast transfer capabilities, it is expected that the requirements for precise membership information are less stringent in larger scaled conferences. 5.1.1. Examples Examples for simple conferencing include ad-hoc or pre-planned small group meetings, rich calls, Internet lectures, tele-working in a team. Most of the current MBone [2] sessions are typical examples for simple conferencing. 5.2. Floor Controlled Conferencing Scenarios of this category enrich the simple conferencing functionality of section 5.1. by providing floor control facilities to control the access on distributed resources. Among others, these distributed resources might reflect the commonly used audiovisual channel within the conference but also the content of a shared whiteboard, or a shared, locally hosted application. The floor control semantics are usually known beforehand, or they might be distributed using the conference profile information. The realization of the floor control semantics is usually highly application-specific. For instance, floor controlled conferencing might allow 'conducted meetings', enabling the conductor of a conference for instance to eject participants from a conference or to deny access to the conference. However, in addition to the realization of the social rules by means of floor control, appropriate functionality to enforce them on data level is required by means of excluding receiver sets from reception. Capabilities re-negotiation is usually provided in these scenarios, which might also be tied to the implemented floor control policy of the specific scenario. In floor controlled conferences, there is an exact knowledge of the current membership information of the participants. Usually, the implementation of the floor control restricts the scalability of Trossen Expires November 2001 [6] Internet Draft Course Control Problem Statement May 2001 this type of conferences to a few tens. However, approaches as proposed in [13], might be used in specific scenarios to improve the scalability. 5.2.1. Examples Examples for floor controlled conferences include scenarios with the need to realize social rules or access control on shared resources, such as conducted meetings, application sharing sessions, distance learning including demonstration of shared information, tele-working with common resources to share. 5.3. Rich Conferencing A 'rich conferencing' event, which is going to happen, might be announced beforehand but an ad-hoc establishment might also be considered, such as a 'randomly gathering a crowd around an attraction'. Authentication and authorization means might be used for restricted access to the event. Usually, there is a (small) well-known group of active participants, i.e., exact membership information is required, and a larger group of passive participants. Membership information for this larger group is less strictly provided, comparable with 'blue sheets' attendees lists. The access control within the group of active participants is realized by means of floor control realizing specific social interactions (conducted session, panel group) similar to floor controlled conferencing. As a specific characteristic of this category, frequent changes between active and passive participation in the conference are happening, e.g., a passive observer (participant) of the event might raise its interest in becoming active in the discussion, either by own request or by invitation, following the specific access rules of the active participant group implemented by appropriate floor control means. The mode change could happen 'explicitly', i.e., by joining the active member group, or 'implicitly', i.e., by requesting floor control services. This mode change should be possible in the reverse direction, too, i.e., when an active participant looses interest in active participation. 5.3.1. Examples Examples for large scale rich conferencing scenarios are town hall meetings, IETF working group meetings, virtual lectures with feedback, virtual newsgroups. However, examples for simple and floor controlled conferencing are also applicable for this category due to the superset character of the rich conferencing category compared to the other ones. Trossen Expires November 2001 [7] Internet Draft Course Control Problem Statement May 2001 5.4. Summary of Characteristics The following table summarizes the main characteristics for the different scenario categories presented in section 5.1. to 5.3. '(+)' indicates optional functionality. The first block of characteristics is referred to as conference initiation and setup (see [3]), while the second block is dedicated to conference course control functionality. ---------------------------------------------------------------- | Functionality | Simple | F.C. | Rich | | | Conf. | Conf. | Conf. | ---------------------------------------------------------------- ---------------------------------------------------------------- | Profile Inf. | + | + | + | | | | incl. | incl. | | | | floor inf. | floor inf. | ---------------------------------------------------------------- | Initiation | announced | announced | announced | | | invited | invited | invited | ---------------------------------------------------------------- | Capabilities | (+) | + | + | | Re-negotiation | | | | ---------------------------------------------------------------- | Authentication + | (+) | (+) | (+) | | Authorization | | | | ---------------------------------------------------------------- ---------------------------------------------------------------- | Membership Info | + | + | + | ---------------------------------------------------------------- | Membership | at startup | based on | based on | | Enforcement | only | floor ctrl | floor ctrl | ---------------------------------------------------------------- | Membership | open | open | open | | Model | |closed/static |closed/static | | | |closed/dynamic|closed/dynamic| ---------------------------------------------------------------- ---------------------------------------------------------------- | Floor Control | - | + | + (for | | | | | active) | ---------------------------------------------------------------- | Active/Passive | - | - | + | | Mode Change | | | | ---------------------------------------------------------------- ---------------------------------------------------------------- | Scale | small due to| depends on | large | | | lack of | floor ctrl. | | | | mediation | scale | | ---------------------------------------------------------------- Table 1 : Summary of Characteristics Trossen Expires November 2001 [8] Internet Draft Course Control Problem Statement May 2001 The following Figure 1 tries to outline the categories of this section in a scale-functionality space, emphasizing the superset character of the 'rich conferencing' category. Scale /|\ ||--------------------------------------------------| || Rich Conferencing | || | || Town Hall Meetings, IETF Meetings | |||----------------------||------------------------|| ||| Simple Conferencing || Floor Controlled Conf. || ||| || || ||| Lectures, Meetings || conducted meetings || |||----------------------||------------------------|| ||--------------------------------------------------- |----------------------------------------------------> Functionality Figure 1 : Categories in Scale-Functionality Space 6. Conference Course Control Models The conferencing scenarios in Section 5 can easily be mapped onto models for realize conference course control realization with respect to the functionalities presented in Section 2. 6.1. Loose Conference Course Control 'Loose' conference course control (also referred to as 'light-weight session control' [3]) is the model applicable for the simple conferencing scenario category of Section 5.1. Hence, this control model lacks of explicit membership and application session control. Furthermore, floor control facilities are not provided. However, membership information might be gathered during runtime of the session, comparable with the blue sheets of attendees. Usually, group key mechanisms are also missing for membership enforcement after starting the conference. 6.2. Tight Conference Course Control 'Tight' conference course control [3] is the model applicable for the floor control conferencing scenario categories of Section 5.2. Hence, additional floor control information of the conference profile or statically implemented application semantic are used for implementing floor control to map 'social protocol' semantics onto the distributed scenario. Exact membership and application session information is usually provided together with membership enforcement based on floor control policies during runtime of the conference. Trossen Expires November 2001 [9] Internet Draft Course Control Problem Statement May 2001 6.3. 'Jelly-like' Conference Course Control As a combination of the loose and tight control model of Section 6.1. and 6.2., 'jelly-like' course control is considered for rich conferencing (see Section 5.3.) realization. The tight control model is applied for the active participants in the conference, while a loose control model is used for the passive ones. In addition to the functionality for the specific user group, i.e., active or passive, mechanisms to support mode changes from active to passive and vice versa might be required without disturbance, i.e., interruption, of the running conference. Different policies for this mode change should be feasible, such as upon invitation by individual active participants or upon request of the passive participant. 7. Existing Solutions The following section is briefly evaluating existing conferencing solutions with respect to their conference course control functionality. Note that this presentation is restricted to systems based on certain standards, hence this list does not claim to be an exhaustive review of existing conferencing systems. The following, intertwined, criteria are used to evaluate these solutions: o Provided Functionality: What functionality is provided with respect to Table 1? o Flexibility: What scenarios are covered? What policies are provided? How flexible is the provided functionality? o Extendibility: To what extent can the solution be extended to integrate new functionality? o Scalability: What restrictions due to architecture? 7.1. H.32x Protocol Suite o Functionality: - centralized/decentralized conferencing - pretty much aiming at floor controlled conferencing, although only conducted/non-conducted modes supported - No passive/active notion in the original H.32x, H.332 extension doesnÆt support changes of listeners to active users. o Flexibility: - Floor controlled conferencing is poorly supported, although the data conferencing part supports tokens. - Pre-defined role models, i.e., conducted versus non-conducted, for audiovisual part. - No policy definition, e.g., using appropriate profile information. - reconfiguration of running conferences poorly supported. Trossen Expires November 2001 [10] Internet Draft Course Control Problem Statement May 2001 o Extendibility: - pretty closed system of a whole set of standards o Scalability: very restricted due to tight centralized control structure [TBD] add other points, either items or subitems 7.2. SIP-based Solutions o Functionality: - flexible initiation models [11] - membership information using RTCP information (loose control) or a-priori information - no membership enforcement - no floor control - no capability re-negotiation o Flexibility/Extendibility: - extension possible by adding conference course control functionality as separated component due to open system character - other scenarios possible by adding functionality o Scalability: depends on the initiation model, but most likely similar to the simple conferencing category (see Section 5.1) [TBD] add other points, either items or subitems 7.3. Transport Layer Solutions Mostly implementing certain session control functionality for specific media types, such as streaming (RTSP), reliable multicast, and so on [TBD] show need to provide transport layer independent functionality which is to be mapped onto specific layer solutions. 8. Next Steps The following items are proposed as next steps: o Definition of requirements o Proposal for provided services o Proposal of protocol solutions o Analysis of protocol solutions o Recommendation of conference course control service and protocol A crucial part of the analysis work is to study existing solutions with respect to their applicability and their alignment with the defined scope of Section 2 and the problem statement in Section 3. Trossen Expires November 2001 [11] Internet Draft Course Control Problem Statement May 2001 9. Security Considerations This document merely discusses problem statements motivating the need for conference course control mechanisms. Security is an issue for conference course control but is considered in subsequent solution-space documents. 10. Acknowledgements I would like to acknowledge the participants of the mailing list that was set up to discuss the this document. Their contributions and active participation in the discussion on the mailing list were very useful in the preparation of this document. 11. References [1] C. Bormann, J. Ott, D. Kutscher, D. Trossen, "Simple Conference Control Protocol û Service Specification", draft-ietf-mmusic- sccp-01.txt, Work in Progress, February 2001 [2] H. Eriksson, "MBONE: The Multicast Backbone", Communications of the ACM, Vol.37 No.8, pp.54-60, August 1994 [3] M. Handley, J. Crowcroft, C. Bormann, "The Internet Multimedia Conferencing Architecture", draft-ietf-mmusic-confarch-03.txt, Work In Progress, July 2000 [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 [5] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999 [6] M. Handley, C. Perkins, E. Whelan, "Session announcement protocol", RFC 2974, October 2000 [7] ITU-T, "Visual Telephone Systems and Equipment for Local Area Networks with Non-Guaranteed Quality of Service", ITU-T Recommendation H.323, 2000 [8] ITU-T, "H.323 extended for loosely coupled conferences", ITU-T Recommendation H.332, September 1998 [9] D. Kutscher, J. Ott, C. Bormann, I. Curcio, "Requirements for Session Description and Capability Negotiation", draft-ietf- mmusic-sdpng-req-01.txt, Work In Progress, April 2001 [10] J. Ott, C. Perkins, D. Kutscher, "A Message Bus for Local Coordination", draft-ietf-mmusic-mbus-transport-06.txt, Work In Progress, May 2001 Trossen Expires November 2001 [12] Internet Draft Course Control Problem Statement May 2001 [11] J. Rosenberg, H. Schulzrinne, "Models for Multi Party Conferencing in SIP", draft-rosenberg-sipping-conferencing- models-00.txt, Work In Progress, November 2001 [12] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996 [13] D. Trossen, "Scalable Floor Control in Conferencing Environments: The RBone Approach", 2nd IP Telephony Workshop, New York, April 2001 Author's Address Dirk Trossen Nokia Research 5 Wayside Road Burlington, MA 02474 USA Phone: 1-781-993-3605 Email: dirk.trossen@nokia.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Trossen Expires November 2001 [13] Internet Draft Course Control Problem Statement May 2001 Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Trossen Expires November 2001 [14]