CLUE WG R. Even Internet-Draft Huawei Intended status: Informational June 11, 2012 Expires: December 13, 2012 CLUE switched and mixed captures use cases draft-even-clue-swithed-use-cases-00.txt Abstract This document describes multi stream use cases using switched and mixed streams. This document present the cases when using the switched and mixed attributes with Boolean values may not provide the best results. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Even Expires December 13, 2012 [Page 1] Internet-Draft Switched use cases June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Even Expires December 13, 2012 [Page 2] Internet-Draft Switched use cases June 2012 1. Introduction The CLUE framework[I-D.ietf-clue-framework] defines "mixed" and "composed" attributes for media captures. Both attributes have a Boolean value. These attributes tell the receiver that the advertised media captures are composed or switched and the content is based on provider logic. using only Boolean values can support basic point to point call scenario and basic multipoint calls scenarios. For example we may have a Telepresence three camera system advertising four Capture Scene Entries (CSE). Note: Left, center and right position for media capture is conveyed using the point of capture and area of capture attributes. (VC1 (Left camera), VC2 (middle Camera), VC3(Right Camera)) (VC4 (left), VC5(right)) (VC6 (Composed)) ( VC7(switched)) On the consumer side a three monitor system may choose the first capture scene entry; a two monitor system may choose the second CSE, it may select VC1 and VC2 or even VC6 or VC7; a single monitor system may choose VC6 or VC7 or decide to ask for VC2 for example. In the centralized multipoint case the MCU may advertise the above CSE allowing the consumer to have a similar selection as the point to point case except that the first two CSE may have switched attribute for all media captures in order to allow the MCU to send views according to a defined policy. Note : The MCU advertisement may define if MCU will do site switch or segment switch using the scene-switch-policy attribute. In the site switch case when the number of the media capturesbetween the source and the receivers does not match it is up to the MCU to decide how to handle the site switch case. The current framework allows this basic set of interoperability. Based on these CSEs, the consumer in a point to point call knows who the source is (both the endpoint and the spatial information). In the multipoint case the mapping for the mixed and switched media captures content to RTP streams should be addressed by the RTP Even Expires December 13, 2012 [Page 3] Internet-Draft Switched use cases June 2012 mapping document. This should allow for a consumer to know whose media he is currently receiving in each switched or mixed media capture. The consumer can get a conference roster using the conference event package. BTW: The MCU can add a text description in each sub-window of the mixed stream presenting to the user readable information about the source. The attributes specified in the current framework[I-D.ietf-clue-framework] without a capability message requires the provider to advertise CSEs that can be used by what he considers as typical TP systems (one to three or four camera/monitors systems). In the above case the consumer cannot control what will be the content of the composed or switched media captures. The advertisement will provides partial information that will enable the consumer to render mixed views using multiple received streams based on consumer logic. Note: The current model allows the provider to update previous advertisements and the consumer to ask for different configurations from the active advertisement using the configure message. The current model does not provide a way for the consumer to provide any information about his system hardware and software capabilities (like number of monitors, ability to mix multiple streams to render a mixed/switched view). There is a capability message in the current framework [I-D.ietf-clue-framework] but it is not specified and it seems that there will be a consensus to remove it. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119[RFC2119] and indicate requirement levels for compliant RTP implementations. 3. Use Cases There is an interest from the CLUE WG members to look at advanced cases where the consumer wants to get better control over the number and content of the media captures. Some of the examples given o A consumer's system may have more monitors than cameras, these monitors can be used each as a single entity or the consumer would like to group a couple of them to appear as one. Even Expires December 13, 2012 [Page 4] Internet-Draft Switched use cases June 2012 o The consumer's monitors may not be in a one row left to right spatial order. o The consumer wants to render multiple media captures to a single or multiple monitors building his preferred layout. o The consumer may have N monitors for main video and M monitors for presentation where N+M is fixed while N and M can change for each call or during a call. The above examples represent part of the possible cases where the consumer wants control over the content of the media captures and of cases where the consumer provides more information to the provider about his hardware and software capabilities. The document will try to list such cases. Some of these cases can be merged. 1. The provider offers multiple mixed captures. Currently the only attribute has a Boolean value. The provider would like to provide more information about the mixes content allowing the consumer to select a relevant one. 2. The provider would like to offer only media captures that are useful to the consumer. The simple case is based on the number of available monitors for main video. 3. The consumer will provide more information about his preferences for example the total number of monitors that can be used dynamically for all types of media (number of speakers, number of monitors for main or presentation video, the number of simultaneous video streams that the consumer can decode ...). The provider will advertise relevant CSEs that he can support to address these preferences. It may be more than one option. 4. The MCU will offer mixed media captures (one or more) in one or more CSEs. The consumer want to select how many sources are in each mixed capture and how the layout should look. This will allow each consumer to create a personal layout if the MCU allows this functionality. The MCU is doing the actual mix in the case. 5. The MCU will offer multiple media captures in one or more CSEs. The consumer want to select who will be seen in each mixed capture knowing the number of maximum media streams that can compose the mix. This use cases adds to the previous one the ability to control the policy by which streams are added or removed from a mix. Even Expires December 13, 2012 [Page 5] Internet-Draft Switched use cases June 2012 6. The MCU will offer multiple switched media captures in one or more CSEs. The consumer wants to define a switching policy for each of the switched streams. 7. The MCU will offer multiple switched and mixed media captures in one or more CSEs. The consumer would like to define the layouts topology. 8. The MCU will offer multiple switched and mixed media captures in one or more CSEs. The consumer would like to know what the available layouts are and optionally define who is in each sub- window of the layout by defining policy or by selecting specific individuals. 9. The consumer would like to get multiple media captures and create his own views. The media capture may be a switched stream. The information available to the consumer should include the identity of the stream and its spatial information (example left camera from TPRoom1). The information should be available when a switch occurs. 10. The consumer would like to define layouts to the provider to be used for the media captures. The consumer accepts a mixed or switched stream in each sub-window. The maximum number of switched streams will be the number of sub-windows. The consumer will need to know who is the current stream in a mixed capture including his spatial information. Things to consider. o Which cases we want to support and why not to support the others. o Are there more use cases. o The current framework talks about adding attributes. It does not talk about adding new message to the call flow. A new message may be needed from the consumer to the provider to address this case unless the configure message will be used for it which may require adding a child element to the clue-info element from the data model individual draft. o These cases require more information from provider to consumer. They also require the consumer to provide information to the provider. At the February interim meeting it was suggested to have this type of functionality in future extensions. Is this still how we feel about it. Even Expires December 13, 2012 [Page 6] Internet-Draft Switched use cases June 2012 4. Acknowledgements place holder 5. IANA Considerations TBD 6. Security Considerations TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-clue-framework] Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-05 (work in progress), May 2012. Author's Address Roni Even Huawei Tel Aviv, Israel Email: even.roni@huawei.com Even Expires December 13, 2012 [Page 7]