idnits 2.17.1 draft-even-clue-swithed-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 11, 2012) is 4308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE WG R. Even 3 Internet-Draft Huawei 4 Intended status: Informational June 11, 2012 5 Expires: December 13, 2012 7 CLUE switched and mixed captures use cases 8 draft-even-clue-swithed-use-cases-00.txt 10 Abstract 12 This document describes multi stream use cases using switched and 13 mixed streams. This document present the cases when using the 14 switched and mixed attributes with Boolean values may not provide the 15 best results. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 13, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 The CLUE framework[I-D.ietf-clue-framework] defines "mixed" and 65 "composed" attributes for media captures. Both attributes have a 66 Boolean value. These attributes tell the receiver that the 67 advertised media captures are composed or switched and the content is 68 based on provider logic. 70 using only Boolean values can support basic point to point call 71 scenario and basic multipoint calls scenarios. 73 For example we may have a Telepresence three camera system 74 advertising four Capture Scene Entries (CSE). 76 Note: Left, center and right position for media capture is conveyed 77 using the point of capture and area of capture attributes. 79 (VC1 (Left camera), VC2 (middle Camera), VC3(Right Camera)) 81 (VC4 (left), VC5(right)) 83 (VC6 (Composed)) 85 ( VC7(switched)) 87 On the consumer side a three monitor system may choose the first 88 capture scene entry; a two monitor system may choose the second CSE, 89 it may select VC1 and VC2 or even VC6 or VC7; a single monitor system 90 may choose VC6 or VC7 or decide to ask for VC2 for example. 92 In the centralized multipoint case the MCU may advertise the above 93 CSE allowing the consumer to have a similar selection as the point to 94 point case except that the first two CSE may have switched attribute 95 for all media captures in order to allow the MCU to send views 96 according to a defined policy. 98 Note : The MCU advertisement may define if MCU will do site switch or 99 segment switch using the scene-switch-policy attribute. In the site 100 switch case when the number of the media capturesbetween the source 101 and the receivers does not match it is up to the MCU to decide how to 102 handle the site switch case. 104 The current framework allows this basic set of interoperability. 106 Based on these CSEs, the consumer in a point to point call knows who 107 the source is (both the endpoint and the spatial information). In 108 the multipoint case the mapping for the mixed and switched media 109 captures content to RTP streams should be addressed by the RTP 110 mapping document. This should allow for a consumer to know whose 111 media he is currently receiving in each switched or mixed media 112 capture. The consumer can get a conference roster using the 113 conference event package. BTW: The MCU can add a text description in 114 each sub-window of the mixed stream presenting to the user readable 115 information about the source. 117 The attributes specified in the current 118 framework[I-D.ietf-clue-framework] without a capability message 119 requires the provider to advertise CSEs that can be used by what he 120 considers as typical TP systems (one to three or four camera/monitors 121 systems). 123 In the above case the consumer cannot control what will be the 124 content of the composed or switched media captures. The 125 advertisement will provides partial information that will enable the 126 consumer to render mixed views using multiple received streams based 127 on consumer logic. 129 Note: The current model allows the provider to update previous 130 advertisements and the consumer to ask for different configurations 131 from the active advertisement using the configure message. The 132 current model does not provide a way for the consumer to provide any 133 information about his system hardware and software capabilities (like 134 number of monitors, ability to mix multiple streams to render a 135 mixed/switched view). There is a capability message in the current 136 framework [I-D.ietf-clue-framework] but it is not specified and it 137 seems that there will be a consensus to remove it. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC2119[RFC2119] and 144 indicate requirement levels for compliant RTP implementations. 146 3. Use Cases 148 There is an interest from the CLUE WG members to look at advanced 149 cases where the consumer wants to get better control over the number 150 and content of the media captures. Some of the examples given 152 o A consumer's system may have more monitors than cameras, these 153 monitors can be used each as a single entity or the consumer would 154 like to group a couple of them to appear as one. 156 o The consumer's monitors may not be in a one row left to right 157 spatial order. 159 o The consumer wants to render multiple media captures to a single 160 or multiple monitors building his preferred layout. 162 o The consumer may have N monitors for main video and M monitors for 163 presentation where N+M is fixed while N and M can change for each 164 call or during a call. 166 The above examples represent part of the possible cases where the 167 consumer wants control over the content of the media captures and of 168 cases where the consumer provides more information to the provider 169 about his hardware and software capabilities. 171 The document will try to list such cases. Some of these cases can be 172 merged. 174 1. The provider offers multiple mixed captures. Currently the only 175 attribute has a Boolean value. The provider would like to 176 provide more information about the mixes content allowing the 177 consumer to select a relevant one. 179 2. The provider would like to offer only media captures that are 180 useful to the consumer. The simple case is based on the number 181 of available monitors for main video. 183 3. The consumer will provide more information about his preferences 184 for example the total number of monitors that can be used 185 dynamically for all types of media (number of speakers, number 186 of monitors for main or presentation video, the number of 187 simultaneous video streams that the consumer can decode ...). 188 The provider will advertise relevant CSEs that he can support to 189 address these preferences. It may be more than one option. 191 4. The MCU will offer mixed media captures (one or more) in one or 192 more CSEs. The consumer want to select how many sources are in 193 each mixed capture and how the layout should look. This will 194 allow each consumer to create a personal layout if the MCU 195 allows this functionality. The MCU is doing the actual mix in 196 the case. 198 5. The MCU will offer multiple media captures in one or more CSEs. 199 The consumer want to select who will be seen in each mixed 200 capture knowing the number of maximum media streams that can 201 compose the mix. This use cases adds to the previous one the 202 ability to control the policy by which streams are added or 203 removed from a mix. 205 6. The MCU will offer multiple switched media captures in one or 206 more CSEs. The consumer wants to define a switching policy for 207 each of the switched streams. 209 7. The MCU will offer multiple switched and mixed media captures in 210 one or more CSEs. The consumer would like to define the layouts 211 topology. 213 8. The MCU will offer multiple switched and mixed media captures in 214 one or more CSEs. The consumer would like to know what the 215 available layouts are and optionally define who is in each sub- 216 window of the layout by defining policy or by selecting specific 217 individuals. 219 9. The consumer would like to get multiple media captures and 220 create his own views. The media capture may be a switched 221 stream. The information available to the consumer should 222 include the identity of the stream and its spatial information 223 (example left camera from TPRoom1). The information should be 224 available when a switch occurs. 226 10. The consumer would like to define layouts to the provider to be 227 used for the media captures. The consumer accepts a mixed or 228 switched stream in each sub-window. The maximum number of 229 switched streams will be the number of sub-windows. The 230 consumer will need to know who is the current stream in a mixed 231 capture including his spatial information. 233 Things to consider. 235 o Which cases we want to support and why not to support the others. 237 o Are there more use cases. 239 o The current framework talks about adding attributes. It does not 240 talk about adding new message to the call flow. A new message may 241 be needed from the consumer to the provider to address this case 242 unless the configure message will be used for it which may require 243 adding a child element to the clue-info element from the data 244 model individual draft. 246 o These cases require more information from provider to consumer. 247 They also require the consumer to provide information to the 248 provider. At the February interim meeting it was suggested to 249 have this type of functionality in future extensions. Is this 250 still how we feel about it. 252 4. Acknowledgements 254 place holder 256 5. IANA Considerations 258 TBD 260 6. Security Considerations 262 TBD. 264 7. References 266 7.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 7.2. Informative References 273 [I-D.ietf-clue-framework] 274 Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, 275 "Framework for Telepresence Multi-Streams", 276 draft-ietf-clue-framework-05 (work in progress), May 2012. 278 Author's Address 280 Roni Even 281 Huawei 282 Tel Aviv, 283 Israel 285 Email: even.roni@huawei.com