idnits 2.17.1 draft-even-xcon-media-policy-requirements-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 revision: the document name given in the document, 'draft-even-xcon-media-policy-requirements-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-even-xcon-media-policy-requirements-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-even-xcon-media-policy-requirements-', but the file name used is 'draft-even-xcon-media-policy-requirements-00' == 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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 184: '...edia conference policy. Mixers MAY be...' RFC 2119 keyword, line 199: '...ized participant MUST be able to speci...' RFC 2119 keyword, line 202: '... REQ-GP2: It MUST be possible for a ...' RFC 2119 keyword, line 205: '... REQ-GP3:It MUST be possible, using ...' RFC 2119 keyword, line 208: '... REQ-GP4: It MUST be possible, using...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 10 has weird spacing: '... policy requi...' == Line 42 has weird spacing: '...nes the requi...' == Line 288 has weird spacing: '...amework for C...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 22, 2003) is 7613 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) == Unused Reference: '3' is defined on line 293, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 5 errors (**), 1 flaw (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON BOF R. Even 3 Internet-Draft Polycom 4 Expires: December 21, 2003 O. Levin 5 RADVISION 6 N. Ismail 7 Cisco Systems, Inc. 8 June 22, 2003 10 Conferencing media policy requirements 11 draft-even-xcon-media-policy-requirements- 00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 21, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document defines the requirements for Media Policy, i.e. a set 43 of rules associated with the media distribution of the conference. 44 This document presents the requirements for the media manipulations 45 that can be done using these rules by conference participants or 46 third parties using any kind of media/conference policy control 47 protocol. This document does not address the interface between the 48 focus and the media policy. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. High Level Architecture . . . . . . . . . . . . . . . . . . . 3 56 5. Media Policy Data Model . . . . . . . . . . . . . . . . . . . 5 57 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Media Policy Requirements . . . . . . . . . . . . . . . . . . 6 59 6.1 Genera Media Policy Requirements . . . . . . . . . . . . . . . 6 60 6.2 Video specific requirements . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 64 Intellectual Property and Copyright Statements . . . . . . . . 9 66 1. Introduction 68 The Conferencing Framework [2] presents an overall framework and 69 defines the terminology for SIP [1] tightly coupled conferencing. 70 The conferencing framework architecture includes the media policy. 71 This is a set of rules that describes the media distribution of a 72 conference. This document presents the requirements for the media 73 policy data model and for the manipulations on these rules by 74 conference participants or third parties using any kind of media/ 75 conference policy control protocol. This document does not address 76 the interface between the focus and the media policy and between the 77 focus and the media mixer. 79 2. Rational 81 The media policy enables a conference participant or an application 82 server to define and manipulate the content of the media streams 83 going to the conference participants. This will enable applications 84 like sidebars, announcement to specific participants, call centers 85 and panel conferences. 87 3. Terminology 89 The draft relies on the terminology defined in the conferencing 90 framework document[2]. 92 4. High Level Architecture 94 The basic conferencing architecture used in this document is defined 95 in the Conferencing architecture framework [2]. This document 96 focuses on the media policy component and the requirements to 97 manipulate the media policy by authorized entities. 99 An authorized entity can manipulate the media policy using a supplied 100 application. Examples for such applications include a web 101 application, an interactive voice response application, an 102 interactive Instant Messaging (IM) base application, or an 103 application that uses the media policy control protocol. 105 The Conference policy control protocol (CPCP) provides a standard way 106 for an automated authorized entity to manipulate the media policy. 107 The requirements and definition of the CPCP protocol are out of scope 108 of this document. 110 The media policy is a set of rules that describes the media mixing or 111 switching required for each participant in the conference. This 112 includes the set of sources to be mixed or switched and the rules for 113 their mixing or switching. The focus uses the media policy to 114 determine the proper configuration of the mixers. Authorized 115 entities will be notified of changes to the media policy by 116 subscribing to the conference event package. The information about 117 the current contributing sources to the mixed streams can be learned 118 by the information in the RTP header or by the conference event 119 package [4]. The data structures that include the contributing 120 sources of the current streams is in the focus or the mixer and is 121 not in the scope of the work. 123 The initial state of the media policy data structure is defined at 124 the conference creation time. It can be either provisioned or 125 created by using a conference policy control protocol or/and other 126 protocols being used to create the conference. 128 Typically, a focus has access to the media policy and is responsible 129 for translating the media policy data into the actions towards the 130 physical entities ("mixers"). 132 Figure 1 describes an instance of media policy of a conference. The 133 figure shows a single mixer and a single type of stream for ease of 134 drawing but the model does not have such a restriction. 136 Conference . 137 Policy . +-----------+ //-----\\ . 138 Control . | | || || . 139 Protocol . | Conference| \\-----// . 140 +------------->| Policy | | | . 141 | . | Server |----> |Conference . 142 | . | | | | . 143 | . +-----------+ | & | . 144 | . | | . 145 | . | Media | . 146 +------------+ . +-----------+ | Policy| . 147 | +----------++ . | | \ // . 148 | | || . | | \-----/ . 149 |Participants||<-------->| Focus | | . 150 | | || SIP . | | | . 151 | | || Dialog . | |<-----------+ . 152 +-+----------++ . +-----------+ . 153 +-----------+ . | . 154 ^ | . | . 155 | | Contributing . | . 156 | | Streams . +-----------+ . 157 | +------------->. | | . 158 | Distributed . | Mixer | . 159 | Streams . | | . 160 +-------------------. +-----------+ . 161 ..................................... 163 Conference 164 Functions 166 Figure 1: Media Policy in a Conference 168 5. Media Policy Data Model 170 5.1 General 172 The fundamental conferencing functionality is being able to combine 173 (i.e. "to mix") in a media specific manner participants' streams 174 that belong to a logical sub-function within a conference (such as 175 participant's video, left audio stream, right audio stream, video 176 streaming presentation, slide presentation) and are of the same media 177 type (such as video, audio, etc.). In the case of using 178 centralized-mixing the resultant stream(s) will be sent back to the 179 participants. In the case of end-point mixing, the original streams, 180 needed to produce the mixed media, will be distributed to the 181 participants that will perform the actual mixing. 183 Typically, the maximum number of different mixers in a conference is 184 preconfigured as part of the media conference policy. Mixers MAY be 185 dynamically created and destroyed during the conference lifetime. 186 This document will not describe the data model itself. 188 6. Media Policy Requirements 190 All the requirements are based on having a privilege mechanism that 191 authorizes users to access and manipulate the media policy data. The 192 requirements are for the manipulations that can be done on the media 193 distrbution by the mixer using the CPCP protocol. The protocol 194 itself is not in the scope of this document. Authorization is also 195 part of CPCP. The requirements are not for the mixer itself. 197 6.1 Genera Media Policy Requirements 199 REQ-GP1: An authorized participant MUST be able to specify its own 200 unique topology. 202 REQ-GP2: It MUST be possible for a group of users to receive the same 203 mix. This mix may be a conference common mix. 205 REQ-GP3:It MUST be possible, using the protocol, to dynamically 206 modify the number of contributing streams associated with a mixer. 208 REQ-GP4: It MUST be possible, using the protocol, to define the 209 mixing function for each participant in the conference. 211 REQ-GP6: It SHOULD be possible to send a participant multiple streams 212 from one mixer. This requirement is to enable support for end- point 213 mixing. 215 REQ-GP7: It SHOULD be possible to define relationships between 216 different mixers. The relationships can be time synchronized such as 217 specifying that the audio mixer and video mixer is a pair to 218 establish lip-synchs. 220 REQ-GP8: It SHOULD be possible to define the number of different 221 topologies and the number of streams in each of them that will be 222 mixed in a mixer. For example the conference will support only one 223 video topology that will go to all the participants, the video 224 topology will support 2x2 display, or each participant will be able 225 to receive his own audio topology that will include up to 4 226 contributing sources. 228 REQ-GP9: It SHOULD be possible to have more then one stream from the 229 same type (video or audio) coming from the same user and to mix them 230 separatly. For example one video stream will be the video camera 231 showing the speakerwhile the other may be a presntation or a second 232 camera showing the whole room. 234 6.2 Video specific requirements 236 Video is a bit different than audio when mixing is concerned. In 237 multipoint video the common mixing modes are: 239 Video switching where one of the contributing sources is sent to all 240 participants, the video source may be forced by the media policy 241 control protocol or may be dynamic by using for example a voice 242 activated video switching mode where the participants will see the 243 loudest speaker. 245 "Continuous presence" or tiled windows display where the topology is 246 composing one video stream that has a layout defining the shape and 247 position of viewing windows that will be displayed to the 248 participants. The layout includes N viewing windows so that in each 249 of the windows there is one contributing stream. Even though the 250 viewing windows can be of any shape we will address in this work only 251 rectangular windows of any size. The windows may overlap. 253 The section defines the specific requirements for media policy and 254 media policy control to enable "Continuous presence" 256 REQ-V1: It should be possible to define rectangular overlapping 257 windows in a video mix. 259 REQ-V2: It should be possible to map a stream to a window based on 260 some mode like having one window display the loudest speaker or the 261 floor holder while for the remaining windows fixed input streams are 262 used. 264 REQ-V3: It should be possible for authorized participants to change 265 the layout of the video topology. 267 REQ-V4: It should be possible for authorized participants to define 268 the mapping of a stream to a window. 270 7. Security Considerations 272 The media policy control protocol may enables unauthorized users to 273 manipulate the media mixing of conferences, this may enable them to 274 listen to conference or eject unsolicited media streams. The 275 protocol should provide authentication of the users. The media 276 policy data may include information about the sources and targets of 277 mixer, if this information will be transferred in the protocol in the 278 clear that may cause a security risk. The protocol should allow for 279 encryption of the media policy transferred in the media policy 280 control protocol. 282 References 284 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 285 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 286 Session Initiation Protocol", RFC 3261, June 2002. 288 [2] Rosenberg, J., "A Framework for Conferencing with the Session 289 Initiation Protocol", draft- 290 rosenberg-sipping-conferencing-framework-01 (work in progress), 291 February 2003. 293 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 294 Session Description Protocol (SDP)", RFC 3264, June 2002. 296 [4] Rosenberg, J. and H. Schulzrinne, "A session initiation 297 protocol (SIP) event package for conference state", , June 2002. 299 Authors' Addresses 301 Roni Even 302 Polycom 303 94 Derech Em Hamoshavot 304 Petach Tikva 49130 305 Israel 307 EMail: roni.even@polycom.co.il 309 Orit Levin 310 RADVISION 311 266 Harristown Road 312 Glen Rock 313 NJ USA 315 EMail: orit@radvision.com 317 Nermeen Ismail 318 Cisco Systems, Inc. 319 170 West Tasman Drive 320 San Jose 95134 321 CA USA 323 EMail: nismail@cisco.com 325 Intellectual Property Statement 327 The IETF takes no position regarding the validity or scope of any 328 intellectual property or other rights that might be claimed to 329 pertain to the implementation or use of the technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; neither does it represent that it 332 has made any effort to identify any such rights. Information on the 333 IETF's procedures with respect to rights in standards-track and 334 standards-related documentation can be found in BCP-11. Copies of 335 claims of rights made available for publication and any assurances of 336 licenses to be made available, or the result of an attempt made to 337 obtain a general license or permission for the use of such 338 proprietary rights by implementors or users of this specification can 339 be obtained from the IETF Secretariat. 341 The IETF invites any interested party to bring to its attention any 342 copyrights, patents or patent applications, or other proprietary 343 rights which may cover technology that may be required to practice 344 this standard. Please address the information to the IETF Executive 345 Director. 347 Full Copyright Statement 349 Copyright (C) The Internet Society (2003). All Rights Reserved. 351 This document and translations of it may be copied and furnished to 352 others, and derivative works that comment on or otherwise explain it 353 or assist in its implementation may be prepared, copied, published 354 and distributed, in whole or in part, without restriction of any 355 kind, provided that the above copyright notice and this paragraph are 356 included on all such copies and derivative works. However, this 357 document itself may not be modified in any way, such as by removing 358 the copyright notice or references to the Internet Society or other 359 Internet organizations, except as needed for the purpose of 360 developing Internet standards in which case the procedures for 361 copyrights defined in the Internet Standards process must be 362 followed, or as required to translate it into languages other than 363 English. 365 The limited permissions granted above are perpetual and will not be 366 revoked by the Internet Society or its successors or assignees. 368 This document and the information contained herein is provided on an 369 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 370 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 371 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 372 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 373 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 375 Acknowledgement 377 Funding for the RFC Editor function is currently provided by the 378 Internet Society.