idnits 2.17.1 draft-ott-mmusic-mbus-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 145 has weird spacing: '...em'' as a sy...' == Line 146 has weird spacing: '...onym for ``h...' == Line 147 has weird spacing: '...ves one parti...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9074 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'FIXME' on line 128 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-confarch-00 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sccp-00 -- Possible downref: Normative reference to a draft: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Ott/C. Perkins/D. Kutscher 2 Expires: December 1999 Universitaet Bremen/UCL/Universitaet Bremen 3 June 1999 5 Requirements for Local Conference Control 6 draft-ott-mmusic-mbus-req-00.txt 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 In a variety of conferencing scenarios, a local communication channel 32 is desirable for conference-related information exchange between co- 33 located but otherwise independent application entities, for example 34 those taking part in application sessions that belong to the same 35 conference. In loosely coupled conferences such a mechanism allows 36 for coordination of applications entities to e.g. implement 37 synchronization between media streams or to configure entities 38 without user interaction. It can also be used to implement tightly 39 coupled conferences enabling a conference controller to enforce 40 conference wide control within a end system. 42 This document defines application scenarios and requirements for a 43 coordination infrastructure that provides local coordination within a 44 conferencing end system. 46 This document is intended for discussion in the Multiparty Multimedia 47 Session Control (MMUSIC) working group of the Internet Engineering 48 Task Force. Comments are solicited and should be addressed to the 49 working group's mailing list at confctrl@isi.edu and/or the authors. 51 1. Introduction 53 1.1. Background 55 In the Mbone community a model has arisen whereby a set of loosely 56 coupled tools are used to participate in a conference. A typical 57 scenario is that audio, video and shared workspace functionality is 58 provided by three separate tools (although some combined tools 59 exist). This maps well onto the underlying RTP [5] (as well as 60 other) media streams, which are also transmitted separately. Given 61 such an architecture, it is useful to be able to perform some 62 coordination of the separate media tools. For example, it may be 63 desirable to communicate playout-point information between audio and 64 video tools, in order to implement lip-synchronisation, to arbitrate 65 the use of shared resources (such as input devices), etc. 67 A refinement of this architecture relies on the presence of a number 68 of media engines which perform protocol functions as well as 69 capturing and playout of media. In addition, one (or more) 70 (separate) user interface agents exist that interact with and control 71 their media engine(s). Such an approach allows flexibility in the 72 user-interface design and implementation, but obviously requires some 73 means by which the various involved agents may communicate with one 74 another. This is particularly desirable to enable a coherent 75 response to a user's conference-related actions (such as joining or 76 leaving a conference). 78 Although current practice in the Mbone community is to work with a 79 loosely coupled conference control model, situations arise where this 80 is not appropriate and a more tightly coupled wide-area conference 81 control protocol must be employed (e.g. for IP telephony). In such 82 cases, it is highly desirable to be able to re-use the existing tools 83 (media engines) available for loosely coupled conferences and 84 integrate them with a system component implementing the tight 85 conference control model. One appropriate means to achieve this 86 integration is a communication channel that allows a dedicated 87 conference control entity to ``remotely'' control the media engines 88 in addition to or instead of their respective user interfaces. 90 Different approaches have been developed in conferencing systems in 91 the past ([2] [3]) and some general purpose system exist (). 93 1.2. Purpose 95 The purpose of this document is to present some common scenarios for 96 conference end system coordination and to derive a set of useful 97 requirements that help to clarify the purpose, the architecture and 98 the scope of a coordination infractructure with respect to the goals 99 of this IETF working group. 101 The main issues in this discussion are: 103 o Which are the architectural and protocol definition relevant 104 requirements? 106 o Is it useful to consider such a coordination facility to be of 107 general use for arbitrary applications that require coordination 108 of distributed entities or would a solution that concentrates on 109 coordination of conferencing systems only be more appropriate? 111 o What will be the role of the MMUSIC working group concerning the 112 development of an infrastructure and protocol definition for the 113 mentioned applications? 115 1.3. Terminology for requirement specifications 117 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 118 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 119 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 120 indicate requirement levels for compliant Mbus implementations. 122 1.4. Definition of terms 124 o Conference 126 The relationship between a set of human beings that are 127 communicating with each other. In this document, the term is 128 used for both tightly and loosely coupled [FIXME] computer based 129 conferences. 131 o Participant 133 A (typically human) being in a conference. 135 o Member 137 The system, including all software and hardware components, that 138 is used in a teleconference to represent a single participant. 140 o End system 142 A host or a set of locally interconnected hosts[1] that is used 143 as an interface to a teleconference by a single participant. 144 _________________________ 145 [1] In this document, we use the term ``end system'' as a syn- 146 onym for ``host'' in the simplest case. We do not want to ex- 147 clude, however, that the local system that serves one participant 148 may be composed of several ``hosts'' in the Internet sense. 150 The end system runs all the required conferencing software (e.g. 151 media agents, session directory, and a confernce controller). 152 End system and software together constitute a member in each of 153 the conferences a user participates in. 155 o Conference controller 157 A dedicated application running on an end system that implements 158 a horizontal conference control protocol through which it 159 interacts with conference controllers on other end systems to 160 implement conference control mechanisms and conference policies. 161 The conference controller constitutes the electronic 162 representation of its (human) user and her actions with respect 163 to conference(s) as a whole (rather than with respect to 164 individual media sessions). 166 o UCI 168 A universal communication identifier of a person. This may be 169 the e-mail address of an individual (or some other globally 170 unique identifier) that is part of the information to identify 171 her within a conference but can also be used to invite her via 172 the Session Initiation Protocol (SIP) [6] protocol. 174 o Presence 176 A presence corresponds to a person (identified by a UCI) being 177 ``logged in'' at an end system and available for conferencing, 178 i.e. a presence may be identified by the pair of a user's UCI 179 and the respective end system's identification (such as a host 180 name). A presence of a user may appear in many conferences (see 181 below). 183 o Appearance 185 An instantiation of a user's presence actually participating 186 (i.e. appearing) in a conference is referred to as an 187 appearance. There is a one-to-one correspondence between 188 appearances and members. 190 o Application session (AS), Session 192 The set of media agents/applications that act as peers to each 193 other within a conference. For real-time data, this generally 194 will be an RTP session [5]; for other application protocols, 195 other horizontal protocols may define their own type of session 196 concept. Possible synonyms are ``application group'' or ``media 197 agent group''. 199 o Application instance, application entity, media agent 201 A program instance taking part in an application session for a 202 conference participant. There can be more than one instance of 203 the same program in one session, there can also be more than one 204 instance in different sessions. 206 2. Scenarios 208 In this section we present a few sample scenarios for the application 209 of an coordination infrastructure. 211 2.1. Conferencing End System 213 We consider two different kinds of conferencing models: 215 o Loosely coupled conferencing [4], realized with light-weight 216 sessions without explicit membership and conference control 217 mechanisms. 219 o Tightly coupled conferencing where explicit membership and 220 conference control mechanisms are applied. Enforcement of 221 conference control can be provided by a ``conference 222 controller'' -- a dedicated control component of an end systen. 224 2.1.1. Loosely Coupled Conferencing 226 A typical end system for loosely coupled conferencing consists of a 227 set of media tools and (usually) a session directory for conference 228 discovery and/or invitations. When joining a conference the session 229 directory launches the media tools with certain parameters for 230 multicast/host address, port number and codec details as announced in 231 the session decription (SDP [5]). The tools can be controlled 232 individually by the user, e.g. they can be terminated, suspended and 233 their configuration can be changed. 235 After the media tools have been lauched there is no way to control 236 their behaviour. If a common communication infrastructure existed 237 within an end system several additional services would be possible: 239 o Coordinated termination/suspension 241 Media tools could be terminated in an orderly fashion at the end 242 of a conference upon receiving a ``quit''-message. 244 o Automatic source selection 246 A video tool could automatically display the video picture of 247 the currently talking participant if an audio tool had the 248 possibility to share this information to other media tools. Lip 249 synchronization would be another example in this category. 251 o Remote control of media tools 253 Certain functions like muting/unmuting sources or configuring 254 communication parameters do not necessarily have to be initiated 255 directly via each tool's graphical user interface. Instead a 256 controlling tool could integrate common functions and distribute 257 control messages to the media tools. 259 o Failure detection 261 Abnormal termination of media tools could be detected and dealt 262 with appropriately. By sending regular ``alive'' messages 263 entities can notice the existence of other entities and by not 264 receiving further messages continously they can detect failure 265 situations. 267 2.1.2. Tightly Coupled Conferencing 269 In a tightly coupled conferencing setting all of the aforementioned 270 features will also be useful but there will be additional (conference 271 wide) control aspects that will be highlighted in the following. 273 Explicit membership and conference control are usually implemented by 274 conference controllers that are components of end systems. Conference 275 controllers can maintain a conference state by applying a horizontal 276 conference control protocol, e.g. SCCP [6]. 278 Integrating a conference controller into an end system requires a 279 local communication infrastructure that needs to provide some 280 additional services compared to the loosely coupled scenario: 282 o Capability exchange 284 One task of a conference controller can be to gather properties 285 of the local end system concerncing supported media types and 286 codecs and to enter a capability negotiation phase before 287 setting up a conference. This would require the controller to 288 obtain a capability description from each media tool and to 289 later inform the end system of the result of the capability 290 negotiation. 292 o Floor control 294 One aspect of conference control in tightly coupled conferences 295 is to formally control who is allowed talk (or send other media 296 data) at a given time. A conference controller has to delegate 297 floor request from the local end system to the conference 298 control session and to enforce the floor control at its local 299 end system by sending appropriate control commands via the local 300 coordination infrastructure. 302 2.1.3. Summary of Requirements for local Coordination in a Conferencing 303 End System 305 The scenarios described here assume end system composed of different 306 entities using a local coordination infrastructure: There are open 307 groups of entities, flexible configuration of entity sets, and user 308 interaction. In detail this means: 310 Local coordination involves a widely varying number of entities: some 311 messages may need to be destined for all local application entities, 312 such as membership information, floor control notifications, 313 dissemination of conference state changes, etc. Messages may also be 314 targeted at a certain application class (e.g. all whiteboards or all 315 audio tools) or agent type (e.g. all user interfaces rather than all 316 media engines). Or there may be any (application- or message- 317 specific) subgrouping defining the intended recipients, e.g. messages 318 related to media synchronization. Finally there will be messages 319 that are directed to a single entity, for example, specific 320 configuration settings that a conference controller sends to a 321 application entity or query-response exchanges between any local 322 server and its clients. 324 Furthermore, messages exchanged between application entities may have 325 different reliability requirements (which are typically derived from 326 their semantics). Some messages will have a rather informational 327 character conveying ephemeral state information (which is 328 refreshed/updated periodically), such as the volume meter level of an 329 audio receiver entity to be displayed by its user interface agent. 330 Certain messages (such as queries for parameters or queries to local 331 servers) may require a response from the peer(s) thereby providing an 332 explicit acknowledgment to the application. Other messages will 333 modify the application or conference state and hence it is crucial 334 that they do not get lost. The latter type of message has to be 335 delivered reliably to the recipient, whereas message of the first 336 type do not require reliability mechanisms at the Mbus transport 337 layer. For messages confirmed at the application layer it is up to 338 the discretion of the application whether or not to use a reliable 339 transport underneath. 341 The communication model varies for different applications: In some 342 circumstances, e.g. when a controller requests capability 343 descriptions from an entity, a request/response scheme is applied 344 whereas in other situations, e.g. when an audio tool signals the 345 beginning of a new talkspurt, frequently sent indications are used. 347 In some cases, application entities will want to tailor the degree of 348 reliability to their needs, others will want to rely on the 349 underlying transport to ensure delivery of the messages -- and this 350 may be different for each message. 352 Finally, accidental or malicious disturbance of communications 353 through messages originated by applications from other users needs to 354 be prevented. 356 The requirements that can be obtained from this are: 358 o reliablity (sometimes): failures (e.g. of entities) must be 359 detectable 361 o scalability (concerning number of entities) 363 o security (authentication and encryption) 365 o well-defined PDU set (to allow for interoperability) 367 o extensibility (concerning PDUs and semantics) 369 o efficiency (small overhead, low latency) 371 o simplicity (easy to implement) 373 2.2. Media Gateway System 375 The following scenario describes a media gateway constituted of 376 different entitities using a local coordination infrastructure. It is 377 simliar to the conference controller scenario. The main difference is 378 that usually direct user interaction is not required. 380 If we assume a media gateway to be composed of several distinct 381 processed that require coordination, there is also a need for a 382 coordination infrastructure that allows for reliable and unreliable 383 communication within a group of entities. Since a media gateway is 384 usually supposed to run without user interaction this example can 385 impose even stronger requirements for reliability and security. 387 2.3. Wide Area Coordination 389 Wide area, i.e. non local, coordination is a totally different scope 390 and is not considered in detail here. 392 3. Summary of Requirements 394 Taking the previous scenario desriptions into account the following 395 requirements for local coordination infrastructure can be summarized: 397 +---------------------+-----------------------+-----------------------+-----------+ 398 |Requirement | Loosely Coupled Conf. | Tightly Coupled Conf. | Gateway | 399 +---------------------+-----------------------+-----------------------+-----------+ 400 |Reliability | somtimes | sometimes | yes | 401 |Scalability | yes | yes | yes | 402 |Security | sometimes | sometimes | sometimes | 403 |Well-defined PDU set | yes | yes | yes | 404 |Extensibility | yes | yes | yes | 405 |Efficiency | yes | yes | yes | 406 |Simplicity | yes | yes | yes | 407 +---------------------+-----------------------+-----------------------+-----------+ 408 Table 1: Matrix of requirements 410 Most of these requirements are important for all applications. 411 Therefore a common coordination infrastructure for those scenarios is 412 suitable as long as application specific extensions and 413 specializations are possible. 415 4. Conclusions 417 Different applications of multimedia conferencing benefit from a 418 suitable coordination infrastructure. To allow for use in different 419 application scenarios with different configurations it is convenient 420 to seperate mechanisms (transport issues, protocol syntax etc.) from 421 semantics (concrete control command sets, parameters, policies). 423 Such an infrastructure will nevertheless not be of general use 424 because of the specific protocol requirements mentioned above. 426 5. Authors' Addresses 428 Joerg Ott 429 Universitaet Bremen, TZI, MZH 5180 430 Bibliothekstr. 1 431 D-28359 Bremen 432 Germany 433 voice +49 421 201-7028 434 fax +49 421 218-7000 436 Colin Perkins 437 Department of Computer Science 438 University College London 439 Gower Street 440 London WC1E 6BT 441 United Kingdom 443 Dirk Kutscher 444 Universitaet Bremen, TZI, MZH 5160 445 Bibliothekstr. 1 446 D-28359 Bremen 447 Germany 448 voice +49 421 218-7595 449 fax +49 421 218-7000 451 6. References 453 [1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 454 Levels'' RFC 2119, March 1997 456 [2] M. Handley, I. Wakeman, J. Crowcroft, ``The Conference Control 457 Channel Protocol (CCCP): A scalable Base for Building Conference 458 Control Applications'' 460 [3] H. Schulzrinne, ``Dynamic Configuration of Conferencing 461 Applications using Pattern-Matching Multicast'' 463 [4] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet 464 Multimedia Conferencing Architecture,'' Internet Draft draft- 465 ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. 467 [5] M. Handley, V. Jacobson, ``SDP: Session Description Protocol'', 468 RFC 2327, April 1998 470 [6] C. Bormann, J. Ott, C. Reichert, ``Simple Conference Control 471 Protocol'', Internet-Draft draft-ietf-mmusic-sccp-00.txt, work 472 in progress, June 1996