idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 (December 1999) is 8870 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 == Missing Reference: '6' is mentioned on line 172, but not defined -- 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-02 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 6 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: June 2000 Universitaet Bremen/UCL/Universitaet Bremen 3 December 1999 5 Requirements for Local Conference Control 6 draft-ietf-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. 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 In order to be scalable and efficient a protocol for local 325 coordination must reflect these different addressing schemes and 326 allow for addressing single entities directly using transport layer 327 mechanisms in a way that messages with a unique target address are 328 only sent to the specified endpoint address. 330 Furthermore, messages exchanged between application entities may have 331 different reliability requirements (which are typically derived from 332 their semantics). Some messages will have a rather informational 333 character conveying ephemeral state information (which is 334 refreshed/updated periodically), such as the volume meter level of an 335 audio receiver entity to be displayed by its user interface agent. 336 Certain messages (such as queries for parameters or queries to local 337 servers) may require a response from the peer(s) thereby providing an 338 explicit acknowledgment to the application. Other messages will 339 modify the application or conference state and hence it is crucial 340 that they do not get lost. The latter type of message has to be 341 delivered reliably to the recipient, whereas message of the first 342 type do not require reliability mechanisms at the Mbus transport 343 layer. For messages confirmed at the application layer it is up to 344 the discretion of the application whether or not to use a reliable 345 transport underneath. 347 The communication model varies for different applications: In some 348 circumstances, e.g. when a controller requests capability 349 descriptions from an entity, a request/response scheme is applied 350 whereas in other situations, e.g. when an audio tool signals the 351 beginning of a new talkspurt, frequently sent indications are used. 353 In some cases, application entities will want to tailor the degree of 354 reliability to their needs, others will want to rely on the 355 underlying transport to ensure delivery of the messages -- and this 356 may be different for each message. 358 Finally, accidental or malicious disturbance of communications 359 through messages originated by applications from other users needs to 360 be prevented. 362 The requirements that can be obtained from this are: 364 o reliablity (sometimes): failures (e.g. of entities) must be 365 detectable 367 o scalability (concerning number of entities) 369 o security (authentication and encryption) 371 o well-defined PDU set (to allow for interoperability) 373 o extensibility (concerning PDUs and semantics) 375 o efficiency (small overhead, low latency, direct addressing on 376 the transport layer) 378 o simplicity (easy to implement) 380 2.2. Media Gateway System 382 The following scenario describes a media gateway or a media gateway 383 controller constituted of different entities using a local 384 coordination infrastructure to allow for coordination of different 385 modules within a gateway or within a controller system. It is similar 386 to the conference controller scenario. The main difference is that 387 direct user interaction is usually not required. However, media 388 gateway control (controlling media gateways from external control 389 elements such as a media gateway controller) provides a different set 390 of requirements and is thus considered to be out of the scope of 391 "local coordination". 393 If we assume a media gateway or a media gateway controller to be 394 composed of several distinct processes that require coordination, 395 there is also a need for a coordination infrastructure that allows 396 for reliable and unreliable communication within a group of entities. 397 Since a media gateway is usually supposed to run without user 398 interaction this example can impose even stronger requirements for 399 reliability and security. 401 2.3. Wide Area Coordination 402 Wide area, i.e. non local, coordination is a totally different scope 403 and is not considered in detail here. 405 3. Summary of Requirements 407 Taking the previous scenario desriptions into account the following 408 requirements for local coordination infrastructure can be summarized: 410 +---------------------+-----------------------+-----------------------+-----------+ 411 |Requirement | Loosely Coupled Conf. | Tightly Coupled Conf. | Gateway | 412 +---------------------+-----------------------+-----------------------+-----------+ 413 |Reliability | somtimes | sometimes | yes | 414 |Scalability | yes | yes | yes | 415 |Security | sometimes | sometimes | sometimes | 416 |Well-defined PDU set | yes | yes | yes | 417 |Extensibility | yes | yes | yes | 418 |Efficiency | yes | yes | yes | 419 |Simplicity | yes | yes | yes | 420 +---------------------+-----------------------+-----------------------+-----------+ 421 Table 1: Matrix of requirements 423 Most of these requirements are important for all applications. 424 Therefore a common coordination infrastructure for those scenarios is 425 suitable as long as application specific extensions and 426 specializations are possible. 428 4. Conclusions 430 Different applications of multimedia conferencing benefit from a 431 suitable coordination infrastructure. To allow for use in different 432 application scenarios with different configurations it is convenient 433 to seperate mechanisms (transport issues, protocol syntax etc.) from 434 semantics (concrete control command sets, parameters, policies). 436 Such an infrastructure will nevertheless not be of general use 437 because of the specific protocol requirements mentioned above. 439 5. Authors' Addresses 441 Joerg Ott 442 Universitaet Bremen, TZI, MZH 5180 443 Bibliothekstr. 1 444 D-28359 Bremen 445 Germany 446 voice +49 421 201-7028 447 fax +49 421 218-7000 448 Colin Perkins 449 University College London 450 Gower Street 451 London WC1E 6BT 452 United Kingdom 454 Dirk Kutscher 455 Universitaet Bremen, TZI, MZH 5160 456 Bibliothekstr. 1 457 D-28359 Bremen 458 Germany 459 voice +49 421 218-7595 460 fax +49 421 218-7000 462 6. References 464 [1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 465 Levels'' RFC 2119, March 1997 467 [2] M. Handley, I. Wakeman, J. Crowcroft, ``The Conference Control 468 Channel Protocol (CCCP): A scalable Base for Building Conference 469 Control Applications'' 471 [3] H. Schulzrinne, ``Dynamic Configuration of Conferencing 472 Applications using Pattern-Matching Multicast'' 474 [4] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet 475 Multimedia Conferencing Architecture,'' Internet Draft draft- 476 ietf-mmusic-confarch-02.txt, Work in Progress, October 1999. 478 [5] M. Handley, V. Jacobson, ``SDP: Session Description Protocol'', 479 RFC 2327, April 1998